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PROCEDE DE PAIEMENT ELECTRONIQUE PERMETTANT D'EFFECTUER DES TRANSACTIONS- UEES A 
U ACHAT DE BIENS SUR UN RESEAU INFORM AT1QUE. 

57) La procddd utilise un r^aau ouvart (1 0) sur lequel 
3nt connectas das postas sarvaurs da marchands (20) et 
das postas clients (30) at comprand: 

- relaboration par un posta sarveur da marchand d'un tic- 
ket da paiament. concamant un achat envisage antra la 
marchand at un client, at comportant das infomiations rela- 
tives au marchand, au client, k robjat da Tachat at k son 
prix; 

- la transmission du ticket da paiament via le reseau a un 
posta sarveur da paiament (40); 

- la vertfication automatique par la sarveur da paiament si 
la paiament du prbc est autorisa pour le client concama, soit 
par interrogation d'un compta client propra au client tanu 
par la sarveur de paiamant, at destine au paiament das pa- 
tits montants, soit par IntamDgation sur un rasaau bancaira 
(50) indepandant du rasaau infomiatiqua (10) pour las 
paiaments da montants plus dlavas, 

- si la verification est positive, Teiaboration par la sarveur 
da paiament d*un bon de caisse comportant au moins una 
pculia des infomiations du ticket de paiament, at 

- la transmission du bon da caisse au sarveur de mar- 
chand afin d'autorisar la realisation da I'achat. 
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La prcscntc invention conccrac un precede de paieracnt clectroniquc 
pcnnettant d'effcctucr des transactions liecs a Tachat dc biens offcrts par dcs 
marchands au moyen dc services telcmatiqucs via un rcseau de telecommunication 
informatiquc ouvert sur Icquel sont conncctcs des postes scrveurs de marchands et 
dcs postes clients. 

Par reseau informatique ouvert, on entend ici un reseau sur lequei des 
particuliers ou des cntrepriscs peuvent libremcnt sc connecter a la condition de 
disposer d'une adresse, par excmple le reseau -Internet". Les biens conccmes sont 
des produits ou des services, dont la foumiture est realisee hors du reseau aprte la 
conclusion dc la transaction, ou dcs biens immateriels, tels que des informations, 
dont la foumiture peut etre realisee via Ic reseau informatique. 

Divers procedes de paiement clectroniquc ont etc proposes, certains 
ctant deja operationnels. 

Plusieurs procedes sont fondcs sur une nouvelle representation dc la 
mormaie. II s'agit d'une representation clectroniquc, quelquefois denommee jeton 
qui pcut etre purement logiciellc ou partiellcment materiellc, par excmple avec une 
carte a puce. Ces procedes impliqucnt la circulation de mormaie sur le reseau 
informatique, ce qui fx>se des problemcs difficiles de securite vis-a-vis de la 
creation de fausse mormaie. 

D'autres procedes cormus impliqucnt une relation directc avec une 
banque ou un reseau bancairc, en particulier un reseau de carte dc credit. II s'agit 
notamment des procedes bien cormus utilisant dcs terminaux points de vcnte relies 
a un circuit carte bancairc. II s*agit aussi dcs procedes utilisant des cheques 
clectroniques avec une signature clectroniquc pour Tauthentification de Tachcteur. 
Ccst une forme de lettre d'engagcmcnt emise par un achcteur, remise au vendeur ct 
acccptec et recormuc par une banque. 

Les procedes qui impliqucnt a un moment ou un autre de la transaction 
une relation avec le systeme bancairc traditionnel et la misc en oeuvrc d'une 
transaction dans ce systeme prescntent des inconvenients. Ainsi, les transactions 
dans le systeme bancaire ont un cout reel qui devient prohibitif lorsque le montant 
de Tachat est tres faible, par excmple consultation d'une base de doimees. Or, les 
reseaux informatiques sont bicn adaptes a la vcnte de biens de faible valeur, 
principalement dcs biens dMnformation puisque la livraison du bien peut se fairc 
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par Ic reseau lui-memc. En outre, I'acces a un reseau bancaire ou un reseau dc carte 
bancaire doit ctrc hautcment protege, cc qui exclut pratiquement la possibilite d*un 
a c ccs a travers un reseau infonnatique ouvert, tel que Ic reseau "Internet" sur lequel 
des acheteurs potentiels peuvent se connecter. 
5 Uinvention a pour but de foumir un procede pennettant d'cviter les 

inconvenients des procedes connus, en particulier un procede permcttant, sans 
circulation de monnaie clectronique, dc realiser de fa50n simple ct fiable des 
transactions liees a Tachat de biens sur un reseau informatique, et ce aussi bien 
pour des biens de prix cleve nccessitant unc autorisation par le systcme bancaire 
10 traditionnel, que pour des biens de faiblc ou tres faible prix. 

Ce but est atteint grace a un procede du type defini en tete de la 
presente description et comportant, confomicment a I'invcntion, les ctapes dc : 

- elaboration pai un poste scrveur de marchand connectc au reseau 
d'une demandc d'autorisation de transaction, ou ticket de paicment, concemant un 

15 achat envisage entre le marchand ct un client, et comportant des informations 
relatives au marchand, au client, a Tobjet de Tachat et a son prix, 

- transmission du ticket de paiement via Ic reseau informatique a un 
poste scrveur de p>aiement distinct des postes clients et serveurs de marchands, 

- verification automat ique par le serveur de paiement si le paiement du 
20 prix est autorise pour le client concemc, la verification etant effectuee, scion le 

montant du prix a payer, soit par interrogation d'un compte client propre au client, 
tenu par le serveur de paiement, et destine au paiement des pctits montants, soit par 
interrogation sur un reseau bancaire independant du reseau informatique, pour les 
paiements de montants plus cleves, 
25 - si la verification est positive, elaboration par le scrveur de paiement 

d*une autorisation de transaction ou bon de caissc comportant au moins unc paitie 
des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de Tachat. 

30 Ainsi, le procede scion Tinvention est rcmarquable en ce qu'il 

n'implique ni la creation de mormaic electronique, ni la circulation de monnaie 

electronique sur le reseau infonnatique. 

La gestion des transactions est effectuee par un serveur dc paiement 

qui seul peut acceder a un reseau bancaire ou un reseau dc carte bancaire, ct qui 
35 gcrc des comptes clients non bancaires sur lesquels des transactions de faibles 

montants peuvent ctrc effcctuees. 
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Le servcur de paiement gere egalement des comptcs marchands non 
bancaircs utilises pour les transactions de faibles montants. Ainsi, iorsqu'un bon de 
caissc est transmis apres verification par interrogation d'un compte client tenu par 
le serveur de paiement, le montant de Tachat est debite du compte client et crcdite 
S sur un compte marchand propre au marchand conceme et tenu par le serv^eur de 
paiement, ce qui n'entraine pas des couts de traitement eleves. 

Chaque client dispose d'une identite qui lui est propre pour pouvoir 
utiliser le procede de paiement. II doit egalement disposer d'un compte bancaire 
reel, de preference un compte utilisable au moyen du systeme iraditionnel des 

10 cartes bancaires. La verification par le serveur de paiement pcut comprendre une 
phase prealable de validation de Tidentite du client a partir du contenu du ticket de 
paiement. La validation de Tidentite est une operation prealable a Tacces eventuel 
au compte du client, si ie montant de I'achat est faible, et/ou a I'acces au reseau 
bancaire si le montant est plus clcvc. Le serveur de paiement comporte de 

15 preference des moycns, par cxemple une base de donnees, pennettant de 
memoriser les relations entre les identites des clients utilisees pour les transactions 
sur le reseau informatique et des identites bancaires (numeros de comptes 
bancaires ou numeros de cartes de credit) utilisees pour les transactions sur le 
reseau bancaire. On evite de la sorte la circulation d'identites bancaires sur le 

20 reseau informatique. 

Un mode de realisation de I'invention sera maintenant decrit a titre 
indicatif, mais non limitatif, en reference aux dessins armexes sur lesquels : 

- la figure 1 est une vue gencrale trcs schcmatique d'un systeme de 
paiement clectronique conformc a Tinvcntion ; 

25 - la figure 2 est une representation sous forme d'un schema bloc d'un 

serveur de paiement du systeme de la figure 1 ; 

- la figure 3 illustrc le deroulement des operations relatives a un achat 
au moyen du systeme de la figure 1 ; et 

- les figures 4A a 4C sont des organigrammes montrant trcs 
30 schematiquement les operations effectuees par le serveur de paiement. 

Sur la figure 1 est rcpresente de faqon tres schematique un reseau de 
telecommunication informatique 10 sur lequcl sont connectes des postes serveurs 
de marchands 20, des postes clients 30 et au moins un poste serveur de paiement 
40. 

35 Le reseau informatique 10 est un reseau ouvert, par exemple le reseau 

"Internet". 
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Les serveuis de marchands 20 sont des unites tellcs que celles 
courammcnt utilisccs pour dcs scrvcurs telematiqucs connectes sur "Internet", par 
exemple des unites organisees autour dc machines "Unix" multiprocesseurs. 

Les postes clients 30 sont csscntiellement des micro-ordinatcurs qui 
5 sont munis de moyens dc connexion au reseau " Internet " 10, par exemple sous 
fonne d'interface "Web". Les serveurs de marchands 20 ct de postes clients 30 
utilisent par exemple des logiciels connus sous la denomination "World Wide 
Web" (WWW) utilisant Ic protocole HTTP. 

Lc serveur de paiemcnt 40 (figure 2) comprend une unite firontale 41 

10 conncctcc au reseau "Internet" 10 et une unite dorsale 42. Lunitc firontale 41 a une 
architecture scmblable a celle d*un serveur classique connectc sur un reseau tel 
qu'" Internet". Uunite dorsale 42 comporte une unite de traitement 43 a un ou 
plusieurs processeuis, une base de donnees 44 relative aux marchands ct clients 
. abonnes au systcme de paiemcnt, un registrc de transactions 45, une unite 46 

15 d'interface avcc un reseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison similaire permettant dc relier entre eux les 
differents constituants dc Tunite dorsale 42, Une liaison sccuriscc 48 pcrmet une 
communication bidirectionnelle entre Tunite firontale 41 et Tunitc dc traitement 43. 
La communication avec lc reseau informatique 10 est contrdlee par Tunitc firontale 

20 41 tandis que la gestion de la base de donnees 44 ainsi que le contrdle de la 
communication avec le reseau bancaire 50 sont assures par Tunite dorsale 42. 

La base de donnees 44 contient des informations relatives aux clients 
et aux marchands abonnes au systcme de paiemcnt. Pour chaque client, la base de 
donnees 44 contient Tidentite systcme du client CId, identite rcguc lors de 

25 Tabonnement au systeme, un comptc de client, ou F>orte monnaic clcctronique 
PME destine au paiemcnt dc faibles montants, une identite bancaire telle que 
numero de comptc bancaire reel ou numero de carte de credit ainsi 
qu'eventuellcment une clef d'acces ou mot de passe propre au client. Pour chaque 
marchand, la base de donnees 44 contient I'identite systeme du marchand Mid, 

30 identite regue lors de Tabonnement au systeme, un comptc de marchand, ou tiroir- 
caissc clcctronique TCE destine a I'encaisscmcnt des faibles montants ct une 
identite bancaire telle que numero de comptc bancaire reel. 

La figure 3 illustre schematiqucment differentes etapes d'une 
transaction portant sur un achat d*un bien par un client aboime a un marchand 

35 abonne. n pcut s'agir d'un bien materiel dont la livraison au client sera effectuce 
rccllemcnt apres conclusion de la transaction ou d'un bien immatcriel tel que de 
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rinfonnation qui pcut ctrc foumic au client par Ic rcscau informatiquc des Ic 
paiement electronique effectue. 

(1) Consultation pgr W cligm 

Par connexion sur Ic reseau "Internet" 10, un client pcut consulter en 
5 lignc le catalogue ou la "vitrine" d'un marchand par acces au seiveur 20 du 
marchand ct visualisation sur Tecran du poste client 30. Sur presentation de 
lidentite CId du client, le serveur du marchand peut presenter au client des 
conditions financicres particulieres (par exeraple une remise). 

(2) Demand? <j'?<Phat 

10 Le choix du client etant arrcte sur un bien O, il est transmis au serveur 

du marchand sous forme d'un message contenant une identite Old du bien et 
I'identite CId du client. Lorsque cela est necessaire, par exemple pour la livraison 
ulterieure du bien choisi, des informations complementaires (par exemple adressc 
et horaire dc livraison) peuvent etre demandees au client en lui adrcssant via le 

15 reseau informatique un formulaire a completer. 

Dans le cas ou Tachat envisage represente un montant eleve ou est 
soumis a des conditions legales, une authentification prealable du client peut etre 
souhaitee. Comme on le vcira en detail plus loin I'authentification d'un client est 
cffectuee par le serveur de paiement 40. Aussi, une demande d'authentification 

20 provenant d'un marchand est emise avantageusement sous la forme d'un ticket de 
paiement de valeur nuUe qui est transmis au serveur de paiement par le reseau 
informatique via le poste client et, en cas d'authentification positive, provoque le 
rctour d'un bon de caisse du serveur de paiement au serveur marchand, toujours via 
le poste client. Les procedures d'etablissement d'un ticket de paiement et de renvoi 

25 d'un bon de caisse sont decrites plus en detail ci-apres. 

La demande d'achat emise par le client peut porter sur un seul bien ou 
sur plusieurs biens a foumir de faqon groupee : "achat panier". 

(3) Elaboration de la demande de paiement 

En reponse a une demande d'achat, le serveur marchand elabore une 
30 demande de paiement qui peut comprendre les informations suivantes : 

- Identite Mid du marchand, 

- Description du bien commande, ou de chacun des biens du panier, en 
cas d'achats groupes, 

- Type de transaction (simple ou panier), 
35 - Identite CId du client, 

- Identite Old du bien ou de I'ensemble des biens du psmier. 
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- Prix dc robjet Old, 

- TVA (si applicable), 

- Date et bcure de remission du ticket de paiement (horodatage par.le 
scrvcur marchand), 

5 - Duree de validite du ticket dc paiement, 

- Numero de serie dans le registre des ventes du marchand (notamment 
dans le cas ou la transaction a comporte une etape prealable d*authentification). 

Uensemble des informations ci*dessus est encodee dans une chaine 
d'octets qui constitue la chaine opaque d'un ticket de paiement (ou URL de 
10 commandc de bien, URL etant Ics initiales de "Uniform Resource Locator" ou 
Localisateur de Ressource Uniforme utilise dans les logiciels WWW avec 
protocole HTTP) : 

URL http : < SP> < dcscriptif de la commando , 
ou SP est I'adressc "Internet" du scrveur de paiement. Le ticket de paiement est 
15 adrcsse au poste client. II est complete par deux ancres qui permettent au client soit 
de Uannuler, soit de le confirmer. 

(4) Envoi de Tordrc de paiement 

Lordre de paiement est transmis au serveur de paiement simplement 
par validation par le client de I'URL de demande de paiement, de sorte que le ticket 
20 de paiement ne fait alors que transiter par le poste client. 

(5) Emission <Jy bon <jg <^is$g 

Sur reception d'un ordre de paiement, le serveur de paiement 40 le 
decode et procede a Tauthentification du client et recherche si le paiement peut etre 
autorise avant de retoumer un bon de caisse ou un refiis de paiement. 

25 Les operations d'authentification de client et d'autorisation de paiement 

scront decrites plus loin en detail en reference a la figure 4. 

Lorsque les veriQcations effectuees nc permettent pas d*autonser le 
paiement, une notification de refus motivee est adressee au client par le serveur de 
paiement (par exemple compte insufGsamment approvisiorme, depassement d*un 

30 seuil autorise pour le client. ...) 

Lorsque les veriQcations effectuees permettent d'autoriscr le paiement, 
les informations contenues dans le ticket de paiement sont completees avec un 
numero de serie dans le registre des transactions 45, une cstampille horaire, une 
duree de validite (typiquement quelques dizaines de secondes) et le sceau du 

35 serveur de paiement constituant une information de certification. L'ensemble de 
ces informations, eventuellement aprcs signature numerique avec une clef privee 
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du scrvcur de paicmcnt garantissant la validite ct Tintcgrite de I'autorisation dc 
paicmcnt, est encode dans unc chaine d'octets qui constituc la chainc opaque d'un 
bon de caisse ou URL dc livraison : 

URL http : <M> <descriptif du bon de caisse> , 
ou <M> est Tadressc "Internet" du marchand. 

(6^ Dcmande de livrai.snn 

Lc bon dc caisse est transmis au scrvcur du marchand via Ic poste 
client. Ceci pcut etrc effectue automatiquement par lc logiciel implantc au poste 
client en utilisant la possibilitc de re-routage des URL Apres decodage du bon dc 
caisse, la validite du bon dc caisse est vcrifiee par lc scrvcur marchand avant 
d'autoriser la livraison du bicn. Cctte verification consistc a controler la clef privec 
cvcntuelle du scrvcur dc paicmcnt, a verifier que la durec dc validite n'cst pas 
ccoulce, et a rapprocher lc contenu du bon dc caisse avcc cclui dc la dcmande dc 
paicmcnt. 

(7) Livraison Vim 

Lorsque lc bon dc caisse est valide par lc scrvcur du marchand, cclui- 
ci pcut effcctuer la livraison dircctc sur lc poste client, dans lc cas dc bicn 
d'information, ou adrcssc au poste client un document permcttant lc rctrait du bicn 
ct precisant notamment lc lieu dc livraison et lc nom du rccipiendairc. 

On notcra que, dans lc cas d*un achat groupc (panier), il y a creation 
par lc scrvcur du marchand d'un objet avcc affectation d'unc idcntitc unique. Get 
objct est la listc des URL dc chacun dcs biens du panier. Ccst cct objet qui est 
indique dans TURL dc commande dc bicn ct qui pcrmcttra d'cnregistrcr lc detail 
des biens achetes dans lc registre dc transaction du serveur dc paicmcnt. 

Lcs figures 4A a 4C montrent Ics operations effectuecs par lc scrvcur 
dc paicmcnt 40 en rcponse a la reception d'un ordre dc paicmcnt. 

Dans Tunitc frontalc 41 (figure 4A), Tordrc dc paicmcnt est decode 
(etapc 61) et sa validite est examinee (test 62) notanmient du point dc vue dc la 
durce dc validite. Si lc rcsultat dc I'examcn est ncgatif, unc notification de refiis est 
envoyec au poste client (etape 63). 

Si le rcsultat dc Tcxamen est positif, il est procede ensuite a unc 
authentification du client (etapc 64), le detail dc cctte operation etant dccrit plus 
loin en reference a la figure 4C. Si Tauthentification est negative (test 65), unc 
notification de rcfus est envoyec au client (etapc 63), Si ellc est positive, Tordre dc 
paicmcnt (eventucllemcnt limite a I'identite CId du client, a I'identite Mid du 
marchand, ct au prix) est transmis via la liaison 68 a Tunite dorsale 42 du scrvcur 
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dc paicmcnt (etapc 66). La liaison 48 est unc liaison securisee interdisant Tacces a 
Tunitc dorsalc a toutc personne sc connectant sur Ic rcseau 10. 

L'unitc firontalc 41 rcstc alors cn attcntc d'un rctour de I'unitc doisalc 
autorisant ou non Ic paiement (ctapc 67). Si le paiemcnt n'cst pas autoris6, (test 68), 
unc notification dc refus est cnvoyee au poste client (etape 63). Si le paiemcnt est 
autorisc, un bon dc caissc est clabore (etapc 69), utilisant les infonnations 
cnrcgistrccs a Tetapc 62. Lc bon dc caissc est cnrcgistre dans unc memoire dc 
Tunite frontalc 41 (etapc 70) et est adressc au serveur du marchand via Ic poste 
client (ctapc 71). 

Au niveau dc I'unite dorsalc 42 (figure 4B), a la reception d'un ordre dc 
paiemcnt aulhentifie, il est examine si celui-ci doit etre autorisc a partir du compte 
client PME ou par interrogation sur lc rcseau bancaire 50. A cet cffet, lc prix est 
compare a un seuil minimum (test 72). Ce seuil est par exemplc dc quelqucs 
. dizaincs de francs. 

Si Ic seuil est depasse, unc demandc pour effectuer Topcration dc 
paiement est lancec sur le rcseau bancaire (ctapc 73) en utilisant Tidentite bancaire 
conespondant a I'identitc CId du client, telle qu'elle ressort dc la consultation dc la 
base de donnees 44. A la reception dc la reponse positive ou negative (etapc 74), 
ccUc-ci est transmisc a Tunitc frontalc 41 (etapc 75). 

Si le seuil n'cst pas depasse, lc paiemcnt peut etre effcctuc a partir du 
compte PME du client. 

A cet effet, il est examine si le compte est suffisamment approvisionne 
(test 76). Dans la negative, un refiis d'autorisation dc paicmcnt, c*cst-a-dirc une 
reponse negative, est renvoyec a Tunite frontalc (ctapc 75). Dans TafErmative, le 
compte PME du client est dcbitc du prix et lc compte TCE dc marchand 
correspondant a I'idcntite Mid est creditc du meme montant* (ctapc 77), la 
transaction est inscrite dans le rcgistre dcs transactions 45 (ctapc 78) et 
I'autorisation de paiement, c'est-a-dire unc reponse positive est transmisc a Tunitc 
frontalc 41 avec Tindication du numcro de scrie dc I'inscription dans le rcgistre dc 
transactions (ctapc 75). 

La procedure d'authentification (figure 4Q a Tetape 64 de la figure 4A 
comprend Tcnvoi securise au poste client d'une demandc de cle d'acces, ou mot de 
passe (etapc 641). A la reception sccurisce de la cle d'acces (etapc 642), une 
comparaison est cffectuee avec une information correspondante contenue dans la 
base dc donnees 44 (test 643). 
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Si la compaxaison est negative, et qu*un nombre maximum de 
tentativcs infnictueuses n'a pas etc atteint (test 644), on rctoume a Tetape 641. Si ce 
nombre maximum est atteint, I'absence d'authentification est constatee, une aleite 
est produite (etape 645) et une reponse negative est claboree (etapc 646). Uaierte 
5 peut consister en une annulation du compte PME ou en une surveillance de celui- 
ci afin de detecter de nouvelles tentatives d*utilisation. Si le test 643 est positif, 
Tauthentification est enregistree (etape 647) et une reponse positive est elaboree 
(etapc 648). 

Des techniques de chiffrement pcrmettant la transmission securisee 
10 d*informations numeriqucs sur reseau informatique, notamment pour la demande 
d'envoi de cle d*acccs et I'envoi de celle-ci, sont bien connues. 

La procedure d'authentification permet d'effectuer une authentification 
prcalable d'un client dans le cas ou ccUc-ci est neccssaire avant Tctablisscment 
d'unc demande de paiement par le scrveur du marchand. Pour cettc 
15 authentification, il suffit alors en effet de creer un ticket de paiement dans lequel le 
prix indique est nul, comme indique plus haut. 

L'enregistrement des bons de caisse dans I'unite frontale permet aux 
clients et aux marchands de proceder a des controles et d'en obtenir eventuellement 
des copies. Uenregistrement des transactions dans I'unite dorsale permet d*en 
20 conserver une trace en cas, par exemple, de contestation entre un client et un 
marchand. 

Lcs comptes clients PME gcrcs par le serveur de paiement ont en 
principe un montant plafonne. lis ne sont pas remuneres, le systeme de paiement se 
trouvant en dehors du monde bancaire. Un rcapprovisionnement de son compte 

25 PME par un client peut etre effectue a partir de son compte bancaire, par ordre 
donne a son etablissement bancaire. 

Les comptes marchands TCE gcres par le serveur de paiement sont 
associes a des comptes bancaires reels des marchands dans lesquels ils sont vides 
par exemple quotidiennement. 

30 Bien que Ton ait decrit ci-avant un mode de mise en oeuvre d*un 

procede scion Tinvention dans un cnvironnement ''Internet" et avec des logiciels 
WWW utilisant le protocole HTTP, Thomme de Tart comprendra aiscment que le 
procede peut etre mis cfi oeuvre avec un reseau informatique autre qu'^Intemet" ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 

35 HTTP de WWW. En outre des procedes d'authentification securises mettant en jcu 
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des dispositifis materiels tel's que lecteur de carte a puce ou moyen de 
reconnaissance d'empreinte vocale pouirontetre prevus ala place de clefis d'acces. 
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REVENDICATIONS 

1. Proccdc dc paicment clectroniquc pour cffectuer des transactions liees 
a Tachat de biens offerts par des marchands a des clients via un reseau de 
telecommunication informatique ouvert sur lequel sont conncctcs des postes 

5 scrveurs de marchands et des postes clients, caracterise en cc qu'il comprcnd ics 
etapes de : 

- elaboration par un poste scrveur dc marchand connectc au reseau 
d'une demandc d'autorisation de transaction, ou ticket dc paiement, concemant un 
achat envisage entrc Ic marchand et un client, ct comportant des informations 

10 relatives au marchand, au client, a Tobjet de Tachat et a son prix, 

- transmission du ticket de paiement via Ic reseau informatique a un 
poste serveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automatique par Ic scrveur de paiement si le paiement du 
prix est autorisc pour le client conccmc, la verification ctant effectuec, scion le 

15 montant du prix a payer, soit par interrogation d'un comptc client propre au client, 
tenu par le serveur de paiement, et destine au paiement des petits montants, soit par 
interrogation sur un reseau bancairc indepcndant du reseau informatique, pour les 
paiements de montants plus eleves, 

- si la verification est positive, elaboration par le serveur de paiement 
20 d*unc autorisation de transaction ou bon de caissc comportant au moins unc partie 

des informations du ticket de paiement, et 

- transmission du bon de caissc au serveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de I'achat. 

2. Procede selon la revendication 1, caracterise en ce que lorsqu'un bon 
25 de caissc est transmis apres verification par interrogation d'un comptc client tenu 

par le serveur dc paiement, le montant de Tachat est debite du comptc client et 
credite sur un comptc marchand propre au marchand conccme et tenu psi le 
scrveur de paiement. 

3. Procede scion Tune quclconque des revendications 1 et 2, caracterise 
30 en ce que la verification par le scrveur de paiement comprend unc phase prcalabic 

d'authentification du client. 

4. Procede selon la revendication 3, caracterise en cc que 
Tauthcntificalion est rcalisee par reconnaissance d*unc clef d'acccs transmisc par Ic 
reseau informatique du poste client au serveur de paiement. 

35 5. Procede scion Tunc quelconquc des revendications 1 a 4, caracterise en 

cc qu*il comprcnd Telaboration par Ic scrveur de paicment d'un bon de caissc 
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comportant au moins une paitie dcs informations du ticket dc paicmcnt ct unc 
information de certification. 

6. Proccdc scion Tune quelconquc dcs rcvcndications 1 a 5, caracterise cn 
cc qu'il comprend la memorisation par Ic scrvcur dc paicmcnt dcs transactions 
autorisces, par stockagc d'au moins une partic du contenu dcs bons dc caissc. 

7. Proccdc scion Tunc quelconquc dcs rcvcndications 1 a 6, caracterise en 
cc que ic ticket dc paicmcnt est transmis du scrvcur du marchand au scrvcur dc 
paicmcnt par i'intcrmcdiairc du poste client. 

8. Proccdc scion Tune quelconquc dcs rcvcndications 1 a 7, caracterise cn 
cc que Ic bon dc caissc est transmis du scrvcur dc paicmcnt au scrvcur du 
marchand par rintcrmcdiaire du poste client. 

9. Systemc de paicmcnt elcctroniquc pour effectuer dcs transactions liees 
a Tachat dc biens offcrts par dcs marchands a dcs clients via un rcscau informatiquc 
ouvert, Ic systemc comportant dcs postes clients ct dcs postes scrvcurs de 
marchands pouvant ctre conncctcs sur le rcscau ouvert, 

systemc caracterise cn cc qu'il comporte cn outre au moins un poste scrvcur dc 
paicmcnt distinct dcs postes clients et scrvcurs de marchands et comprenant : 

- unc unite frontalc munic dc moycns dc cormcxion au reseau ouvert, 

^ - unc unite dorsalc munic dc moycns dc connexion a un rcscau 

"^bancaire indcpcndant du rcscau ouvert, 

- dcs moycns dc communication entre Ics unites frontalc ct dorsale, 

- dcs moycns de memorisation de comptes dc clients, dc comptcs dc 
foumisscurs, ct 

- dcs moycns dc traitcment pour, cn reponse a la reception par I'unite 
frontalc d'unc demande d'autorisation de transaction ou ticket dc paicmcnt, 
conccmant un achat envisage entre un marchand et un client, verifier si le paicmcnt 
du prix est autorisc pour le client conceme par interrogation du comptc du client 
ou du reseau bancairc et, si la verification est positive, claborcr une autorisation de 
transaction, ou bon de caissc afin de la transmettrc sur le reseau ouvert via Tunitc 
frontalc. 

10. Systcme de paiement scion la revendication 9, caracterise en cc que le 
scrvcur de paiement comprend dcs moyens dc memorisation dcs transactions 
autorisccs. 
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